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BACKGROUND OF THE INVENTION 
This application claims the benefit under 35 U.S.C. § 1 19(e) of U.S. Provisional 
Patent Application Serial Number 60/126,003, filed March 24, 1999, entitled "Method for 
Individualized Patient Treatment" for all common subject matter disclosed therein, and 
the contents of said application are hereby incorporated by reference. This application 
also claims the benefit imder 35 U.S.C. § 119(e) of U.S. Provisional Patent Application 
Serial Number 60/168,354, filed December 1, 1999, entitled "Method for Individualized 
Patient Treatment" for all common subject matter disclosed therein, and the contents of 
said application are hereby incorporated by reference. 

1. FIELD OF THE INVENTION 

This invention is in the field of managing patient health through an automated 
online database. More particularly, the system provides for diagnosis and management of 
cardiovascular disease and includes assessment of cardiovascular risk factors and 
providing patient treatment plans. 

2. BACKGROUND OF THE ART 

The art describes cardiovascular risk factors such as age, smoking, weight, family 
history, blood pressure, lipid profiles including low density lipoprotein (LDL) and high 
density lipoprotein (HDL) and subclasses (fi*actions) of LDL and HDL. Methods for 
measuring these factors and relating them to patient treatment are also known. Generally, 
physicians assess a patient's risk factors, make a diagnosis based on test results and 
symptoms and manage patient treatment through drugs, exercise, diet and a variety of 
surgical techniques. Instructions are generally given directly to the patient by the 
physician. Patient compliance generally involves interview in follow-up office visits. 

SUMMARY OF THE INVENTION 
The present invention provides a cardiovascular healthcare management system 
that has an infomediary site, which includes databases with cardiovascular disease risk 
assessment and cardiovascular disease management information. Patient data is stored in 
an information database, and patient test results are stored in a clinical database, both of 
which are selectively accessible to both physicians and patients. Patients' test results and 
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personal information are thus added to the databases and may be viewed by the physician 
to assist in diagnosis. 

A knowledge base may also be included to provide further diagnostic data to a 
physician. The knowledge base may be used as part of a diagnostic engine that analyzes 
5 test results to determine whether they meet certain criteria indicative of a patient's health 
condition, or might simply contain descriptions of risk factors or combinations of risk 
factors that are believed to be indicative of specific health conditions. The knowledge 
base of the preferred embodiment includes software referred to herein as a diagnostic 
engine that performs risk assessments on specific test results and stores risk assessment 
10 information in the database for later viewing by the physician to fiirther assist in 
diagnosis. 

The database also has information related to managing the patient's 
cardiovascular health. The cardiovascular disease (C VD) management system provides 
for the physician having electronic access to the infomediary site for receiving patient test 
1 5 results and entering diagnosis and treatment information to facilitate the building of a 
treatment plan. The treatment plan is created after viewing test results and relevant 
ji patient data and entering any supplemental information including a diagnosis. The 

1==:, treatment plan may include a recommended diet, prescription (and nonprescription) 

M drugs, an exercise regimen, and alternate cardiovascular products that may be available 

£ 20 for purchase through the infomediary site (e.g., blood pressure cuffs to monitor blood 
pressure, anti-embolism support hosiery, dietary products, educational materials, etc.). 
Portions of the treatment plan are preferably derived from templates that are provided by 
the infomediary site 100 . In addition, the infomediary site may present templates having 
the most relevant treatment plan components based in part upon the physician's 
25 previously entered diagnosis information. 

The system also provides for electronic communication between the patient and 
physician by way of access to one or more records in the infomediary site. In this way, 
a physician can electronically provide cardiovascular disease management instruction 
such as diet, exercise and medication to the patient and the patient can electronically 
30 provide compliance information to the physician directly or indirectly via an alternate 
input device. 
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In another aspect of the infomediary site, a case manager may be provided to 
collect and input initial patient data and to perform follow-up services like collecting and 
inputting compliance data to the infomediary site. The case manager may also reviev^ 
initial patient history, test results, and then create a suggested treatment plan for the 
5 cardiologist to review. The cardiologist may accept the treatment plan unchanged or 
modify it, and then electronically release the treatment plan to the patient's folder, which 
stores personalized information within the CVD management system site. The case 
manager also proactively contacts patients to advise and assist in the implementation of 
their treatment plan. 

10 Alternatively, tele-medicine devices may be used to gather compliance 

information for submission to the infomediary site. 



25 Figure 1 illustrates a schematic of the infomediary site 100. It shows physician 102 in 
communication with the site 100 to retrieve test results from a database 104, 
communication of diagnosis information and a treatment plan or other data to the 
database 104 by way of server 112 . The server scripts 1 12 generally provide a "front 
end" to access the records within database 104. Specified records of database 104 are 

30 also made accessible to the respective patients 106 . The patient 106 can view test results, 
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Figure 1 is a block diagram of the infomediary site; 

Figure 2 is a login screen; 

Figure 3 is the physician's welcome screen; 

Figures 4-12 show additional screens available to the physicians; 

Figure 13 is the patient's welcome screen; 

Figures 14-17 show additional screens available to the patient; 

Figures 18-22 show the database tables of the preferred embodiment; 

Figure 23 is a schematic of the cardiovascular informatics; 

Figure 24 is a more detailed block diagram of the infomediary site; and 

Figures 25 and 26 are flow diagrams for methods associated with the infomediary 



site. 



DETAILED DESCRIPTION OF THE INVENTION 



3 



treatment plans, and communications from the physician 102 . and communicate 
compliance infomiation to the physician 102. The lab 108 provides for inputting test 
results into the site. There may also be an optional guest 110 access for reviewing 
Umited data in the system. 

5 PHYSICIAN ACCESS 

The physicians 102 can log-on to the infomediary site 100 and communicate with 
patients 106 and the infomediary site 100 to manage the patient's cardiovascular 
healthcare. The physician 102 first logs in to the site 100 at the login screen 150 by 
entering a usemame in field 152, a password 154, and submitting the data by clicking on 

10 submit button 156 . The physician is then presented with the welcome screen 160 as 

shown in Figure 3. The interface made up of the web pages that provide physician access 
to the site is referred to herein as the physician data access interface. The physician 
welcome screen 160 includes a navigation bar having a plurality of links represented by 
buttons 161 - 169 . The physician welcome screen also includes summary views of certain 

15 data such as the physician's statistics at tab 174 . patient activity at tab 176 and 

professional news at tab 178 . Tabs 174, 176 . and 178 are also links to more detailed 
screens, which can also be accessed by buttons 164 . 161 . and 168 . respectively. 
Preferably, the physician is able to customize his or her own welcome screen to provide 
customized summary information. 

20 The link underlying patient activity button 161 brings the physician to the patient 

activity screen 200 as shown in Figure 4. The patient activity screen 200 is generated by 
ASP script physician_patient_activity.asp. The patient activity screen 200 provides a list 
of patients who may need attention. The physician's attention may be needed due to the 
receipt of new test results (input by the Lab 108 ). the receipt of patient correspondence or 

25 compliance data, or the like. The link underlying patient list button 162 brings the 
physician to the patient list screen 210 as shown in Figure 5, which is preferably 
generated by the ASP script physician__patient_list.asp. The screen 210 contains a list of 
all current (and/or past) patients for that particular physician. The link underlying e-mail 
button 163 brings the physician to the email screen 220 as shown in Figure 6, which is 

30 preferably generated by ASP script physician_email_detail.asp. 
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The names of one or more of the patients of the particular physician are displayed 
on the screens in Figures 4-6. Preferably, the patient name (e.g., 201, 211, and 221 ) is 
also a hypertext link to the patient's data file, thereby providing the physician with 
convenient access to the detailed patient record displayed on a patient folder screen, one 
5 of which is shown at 230 in Figure 7. The patient folder 230 is preferably generated by 
ASP script physician_patient_activity_details.asp. 

The patient folder 230 has a general patient information display area 232, patient 
correspondence display area 234, test results display area 236, FAQ audit trail display 
area 238 , and compliance data display area 240. The patient folder may also contain 

10 patient billing and insurance coverage and/or insurance carrier information (not shown). 
The physician can create initial patient histories by utilizing and editing standard forms. 
Alternatively, a patient may provide medical background information to the infomediary 
site 100 , either by way of the network through an initial registration procedure, or by 
calling a data entry speciahst provided by the infomediary site 100 . Preferably, the 

15 infomediary site provides the physician with the services of the case manager, who is 
typically a lipid nurse, nurse, physician assistant, or other qualified person. The case 
manager may also act as the data entry specialist. 

The general patient information display area 232 contains general patient 
information including name, birth date, medications, insurance information, and salient 

20 medical history information, etc. 

The patient correspondence display area 234 is referred to herein as a 
communication interface. It is presented as an email inbox, but preferably does not 
operate as standard intemet email. That is, physicians preferably communicate with their 
patients by way of the database 104 located at the infomediary site 100. Referring back to 

25 Figure 1, the physicians preferably enter data to be communicated into one or more 

records of database 104 by way of the infomediary server scripts 112 . The server scripts 
112 process physician and patient "email" entries to the database 104 and provide an 
email-type interface. Preferably, actual emails are not sent by the physician, patient or 
infomediary site 100 . Standard email may be utilized in an alternative embodiment; 

30 however, less monitoring and control (e.g., delivery verification) of the communication is 
available when standard email is used. To generate an intemet email from an ASP script, 
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for example, an ASP server running with the^Njj^.O^Option Pack installed and Microsoft 
SMTP Service (from the Option Pack) running may use the CDONTS component. The 
correspondence display area 234 also shoves the status of the email with icons 235 , as 
well as an indication of whether the physician has replied to the patient's email. Of 
5 course, the infomediary site may utilize standard intemet email to notify the patient of 
upcoming appointments for lab test work, doctor office visits, compliance conferences 
with case managers, or to request that the patient log in to the infomediary site to view 
newly posted treatment plans, compliance requests, or for other similar notifications. 

The FAQ audit trail display area 238 allows the physician to view which general 

10 information the particular patient has accessed over the network. This may reveal 

additional information to the physician about the patient's concems that the patient would 
not otherwise convey to his physician. The compliance data display area 240 provides the 
physician with information provided by the patient as to whether the patient has been 
complying with his or her treatment plan. Preferably, the patient provides information to 

15 the case manager who, in accordance with the treatment plan, initiates follow-up contact 
with the patient. The case manager solicits information regarding the patient's 
compliance with the treatment plan such as diet, exercise, medication, and weight and 
blood pressure, if available. The case manager may input the compliance data into the 
information database 104 . Alternatively, the patient may input the data directly via the 

20 infomediary site 100. In addition, with reference to Figure 24, the patient may utilize 
tele-medicine devices to provide compliance-type data. For example, health related 
measurement devices such as a weight scale 115, blood pressure cuff 116 , 
electrocardiogram devices 117 , and the like, may be connected to the network 101 for 
transmitting data to the infomediary site 100 . The device may be connected directly to 

25 the network 101 , or via the patient's home computer, or through a networking device in 
the patient's home. The tele-medicine devices may also be made available at another 
location such as a drug store, etc. The device preferably communicates the measured 
data and automatically submits the data or compliance information to the infomediary 
site. The tele-medicine device may include software (i.e., a resident device driver, or 

30 java-type plug in module) to format appropriately the identification and authentication 
information along with the data for transmission to the site 100 . The physician may be 
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notified of the presence of compliance data either via the email inbox 234 or by listing 
that patient in the patient activity display screen 200 . 

The test results display area 236 shows recent test work, and a test results link 237 
to allow the physician to view the test results. A typical test results screen 260 is shown 
5 in Figure 8. In particular, the test results of Figure 8 show the patient's HDL Gradient 
Gel Electrophoresis in tabular form by HDL subclass, and in graphical form. As seen in 
the table, the test results show the normalized percentages of HDL subfractions, as well 
some points (10%, 50% and 90%) on the distribution of normalized percentages. 
Specifically, the table shows that 10% of people in the sample have a normalized 

10 percentage of HDL Subclass 2b of 4% or more, while 90% have a normalized percentage 
of 18% or less, with the 50% point being 8%. Thus, for example, the physician can see 
that the particular 2b Subclass test result of 15% is generally within the higher ranges. It 
should be noted that more complete tables may be provided to show finer resolution of 
percentages. It should also be noted that the people in the sample to which the test results 

1 5 are compared may vary. In particular, it is often helpfiil for a physician to be able to 
compare test results to a population having a similar diagnosis. To illustrate this, in the 
example shown in Figure 8, the percentages listed are for those people diagnosed with 
coronary artery disease (CAD). Thus, the physician is able to determine that the 
particular results show levels of HDL Subclass 2a and 2b that are higher than average 

20 compared to people with CAD, and levels of HDL Subclass 3a, 3b and 3c that are lower 
than average compared to that same population, and interpret the results accordingly. In 
a preferred embodiment the physician may dynamically select the reference population to 
further assist in making a diagnosis. The doctor preferably has the ability to adjust a 
number of analysis parameters to customize the test result analysis or comparison. The 

25 parameters may specify aspects of the general population used as a reference and may 
include age range, diagnoses, symptoms, LDL and HDL subfraction ranges, etc. The site 
preferably provides default ranges of many analysis parameters to yield comparisons that 
have been determined (via research, data mining, etc.) to be useful in the diagnosis or 
treatment of CVD. 

30 The physician can also view and print current and prior test results including 

patient personal information - name, address and telephone number. With the 
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infomediary site 100 . the physician can view cardiovascular risks from the knowledge 
base, including graphic representation of the patient's condition and test results. Charts 
or histograms comparing current and prior test results are also available from the 
infomediary site database. 
5 The patient folder 230 also includes a diagnosis link 250 , treatment plan link 252 , 

and letter of consultation link 254 . The diagnosis link 250 retrieves the diagnosis screen 
290 as shown in Figure 9. The various diagnoses are shown, with the dates and summary 
information. For example, Diagnosis 1, made in 8/99, would be displayed in field 291 . 
The physician may also create a new diagnosis using link 292 . 

10 The treatment plan link 252 retrieves treatment plan screen 300 as shown in 

Figure 10. The physician can create treatment plans for their patients from information in 
databases of the infomediary site 100. Treatment plan screen 320 includes overview 
display area 302, exercise display area 304 , prescription medication display area 306 
(generic and brand names, as well as the ability to print the prescription, or to specify a 

1 5 pharmacy to where the prescription may be electronically forwarded), diet display area 
308 , cardiovascular (CV) products display area 310 , suggested readings display area 312 , 
adjunct medications display area 314, and follow up display area 316. Each of the 
display areas 302 - 316 include links 320 to pages having fiirther details relating to the 
respective sections. Preferably, the infomediary site provides the physician with a 

20 treatment plan template having the above-referenced components. The physician may 
select specific entries by a number of methods, including drop-down boxes, text boxes, 
bullet lists, etc. In addition, the template may initially provide selections that are 
consistent with the patient's data, including one or more of the following: test results, 
most recent test results, salient patient history, physician diagnosis data, etc. The 

25 finalized treatment plan may also be reviewed by the infomediary site to check for 
consistency of the plan with the same factors, and the physician's attention may be 
directed to aspects of the treatment plan that appear to conflict with the particular 
patient's data. 

The link 254 to the letter of consultation allows the physician to construct letters 
30 of consultation from standard forms, patient data, standard paragraphs and phrases in the 
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infomediary site database 104 . These letters may be printed, stored and sent 
electronically or through regular mail. 

The physician can also, through the infomediary site, visit e-commerce vendor's 
websites to purchase and recommend purchasing to their patients of prescription 
5 medication, adjunct medication, exercise equipment, dietary products, cardiovascular 
products and educational materials, such as reading materials, software, video recordings, 
etc. 

The infomediary site 100 also provides physicians with educational materials such 
as recent news and suggested readings. The infomediary site 100 also provides 

10 physicians with administrative function capability. The physician can perform 

administrative functions, including creating or editing a physician profile, managing 
billing information and logs, and viewing daily activity summaries. 

The infomediary site 100 may also perform insurance pre-certification to ensure 
that requested tests are covered by the patient's insurance. If the test is not covered, the 

1 5 physician and/or patient is notified, and further instructions are requested as to whether 
the physician and/or patient nevertheless wishes to have the test performed. The 
communication can be via telephone fi"om the case manager, or via the infomediary site 
through the physician's "email" inbox. Typically, the infomediary will telephone the 
patient to inform them that the test is not covered or partially not covered. The nature of 

20 the test and the reason for the test is explained to the patient, and the patient may then 
elect to pay for the scheduled test or to decline the test. In the event the test is declined, 
the requesting physician is notified. 

PATIENT COMMUNICATION 

Patients can log-on to the infomediary site 100 and view screens that provide 

25 links to other pages or news. The patient 106 first logs in to the site 100 at the login 
screen 150 (Figure 2) by entering a usemame in field 152, a password 154, and 
submitting the data by clicking on submit button 156 . The patient is then presented with 
the patient welcome screen 340 as shown in Figure 13. The patient welcome screen 340 
includes a navigation bar having a plurality of links represented by buttons 351 - 359. 

30 The patient welcome screen also includes summary views of certain data such as test 

results 341 (as shown further in Figures 14 and 15), diagnosis information 342, treatment 
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plans 343 (as shown further in Figure 16), and email inbox 344 . Figure 17 depicts a 
compliance input screen that may be accessed directly by the patient, or by the case 
manager. 

The patient can communicate with their physician through a communication 
5 interface. Preferably, this takes the form of mutual access to records in the infomediary 
site to obtain doctor treatment plans and report their compliance to the doctor as 
described above with respect to physician email The patient can purchase products, 
including medications, adjunct medications, exercise equipment, dietary products, 
cardiovascular products and educational material directly from the infomediary site 100 . 
10 Additionally, or altematively, the infomediary site may contain links to vendor websites 
for purchasing the products from a third party. 

NON-DOCTOR/NON-PATIENT ACCESS TO THE INFOMEDIARY SYSTEM 

The infomediary system is adapted so that patient results from laboratory tests and 
related information can be inputted into the system. In particular, the site 100 may be 
15 accessed by the lab 108 so that test result data may be input directly through the web site 
server scripts. Altematively, test result data may be input to the system by a data entry 
specialist or by a case manager. 

The infomediary site may also be accessed by guests to the system. Guests may 
browse information, FAQ lists, physician profiles, physician referral services, or request 
20 further infomiation or follow-up contact. 

CARDIOVASCULAR INFORMATICS 

The infomediary site has advanced cardiovascular informatics related to factors 
such as genetics, diet, exercising and medication. The cardiovascular informatics is 
illustrated in Figures 23 and 24. Table 902 illustrates lipid-related data in the 

25 infomediary site IQO. The relationship of lipids 902 to genetic markers 900 and other 

coronary risk and disease factors such as those listed in 904 are analyzed by and stored in 
the CV Therapeutic database 906. Of course, as an initial matter, an individual patient 
might not have every test listed in 900 and 902; however, the infomediary site includes a 
diagnostic engine 113 to identify whether any additional tests should be recommended to 

30 a physician. Note that tables 900, 902, 904 and 908 are shown in siunmary form, but 
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generally take the form of relational database tables such as those shown in Figures 18- 
22, having ID fields, text fields, patient and test ID fields, etc. 

Thus, a cardiovascular risk database is formed from the information in tables 900 . 
902 , and 904 within clinical database 105. Each entry in tables 900 and 902 also includes 
5 fields to identify the patient ID, physician/client ID as necessary, and may optionally 
include one or more suggested diagnosis fields (not shown). The diagnosis fields may 
also be included in another table associated with the patient within clinical database 105 
or information database 104. The diagnosis fields preferably contain diagnosis ID's 
corresponding to the diagnosis text shown in table 904. The diagnosis fields are 
10 populated by the diagnostic engine 113, and are used to convey the analytical results of 
the diagnostic engine to the physician through the physician access interface. The CV 
therapeutic database 906 includes algorithms to identify patterns of risk factors, and may 
;=f compare inputted patient results for lipid subfractions to the normal values. The 

iji algorithms are shown in Figure 24 as a diagnostic engine 113. These algorithms may 

p 15 take the form of software programs or scripts such as SQL scripts or the like. The 

diagnosis engine 113 preferably operates on new test results to identify those results (in 
ijl combination with other risk factors) that fall within the parameters specified by the 

Q algorithm. Additionally, the CV therapeutic database 906 may analyze the lipid 

subfractions in combination with other patient data such as that listed in table 900 and 
20 904. The results, including possible treatments 908 . can then be related to the physician. 
'p. As described above, the measurement of the patient's lipids, genetic markers and 

disease and disorder risk factors and comparison to the database provides a patient's 
specific risk factors which can be related to possible treatments. Furthermore, the book 
"The Heart Disease Breakthrough" by Thomas Yannios, M.D. John Wiley & Sons in 
25 1999 illustrates additional important principals in cardiovascular healthcare that are 

incorporated into the CV therapeutic database 906 and diagnostic engine 113 . This book 
is incorporated herein by reference. The book points out the important role of LDL and 
HDL subfractions in cardiovascular disease. This book further discusses the role of 
genetics, diet, exercising and medication in cardiovascular disease management. 
30 A doctor reviewing the patient's risk factors can formulate an individual course of 

treatment, and the infomediary site 100 provides a list of possible treatments 908, 
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including exercise, diet, pharmaceuticals, which are preferably customized by the CV 
Therapeutic database 906 in response to the risk factors identified by the test results of 
the patient. The physician sends an individualized treatment plan to a patient record in 
the infomediary site and the patient sends compliance information to the physician to the 
5 patient file. Either may access the relevant treatment plan records, but preferably only 
the physician may modify the recommended plan, and the patient may add, update or 
modify the compliance data. 

The quantitative measurement of LDL and HDL lipid fractions and other lipid 
measurements are important patient data that is evaluated in the infomediary site. U.S. 
10 Patent 5,925,229 describes methods for quantitating LDL fractions for evaluating cardiac 
disease risk and that patent is incorporated herein by reference. Typical lipids and their 
method for measurement are listed in Table L 
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TABLE I 

Methodology 

Immunoturbidimetric Analysis 



1 0 Apoprotein B 



Immunoturbidimetric Analysis 



Apoprotein-E Isoforms 



20 Lipoprotein (a) 
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Isoelectric Focusing 



ELISA= Enzyme Linked 
Immunoobsorbant Assay 



Lipid Profile 
Cholesterol 
Triglyceride 
HDL Cholesterol 



LDL Cholesterol 



Homocysteine 



LDL GGE 



Enzymatic 
Enzymatic 

Dextran & Magnesium sulfate 



Calculated ~ Friedewald Formula 

FPIA = Fluorescence 
Polarization Immunoassay 

Gradient Gel Electrophoresis 



HDL GGE 



Gradient Gel Electrophoresis 



S ummary Description of Assay 

An insoluble turbid immunoprecipitate is formed by 
the reaction between Apo A-1 antigen in human 
plasma and specific antibodies. Resulting turbidity is 
measured spectrophorometrically. Concentration of 
Apo A-1 is determined from a five-point calibration 
curve. Patients run in duplicate. 

An insoluble turbid immunoprecipitate is formed by 
the reaction between Apo B antigen in human plasma 
and specific antibodies. Resulting turbidity is 
measured spectrophotometrically. Concentration of 
Apo B is determined from a five point calibration 
curve. Patients run in duplicate. 

Isoelectric focusing of plasma sample is followed 
histochemical visualization of the Apo-E bands. 

Monoclonal/Polyclonal sandwich assay. Monoclonal 
antibody coated wells are used to capture Lp(a) from 
the sample. Polyclonal anti-Lp(a) horseradish 
peroxidase conjugate reacts with substrate and a 
chromogen producing colored solution. 
Concentration of Lp(a) mass (mg/dl) quantitatively 
determined by standard curve 

Patients run in duplicate: 
Photometric quantification 
Photometric quantification 
Precipitation of LDL and VLDL from 
plasma followed by assay of 
supernatant for cholesterol. 
LDL=T Choi - HDL Choi - VLDL (Trig/5) 

Specific monoclonal antibody detection with 
fluorescently labeled analog tracer detection. 

Plasma low density lipoproteins (LDL) are 
characterized for particle size and distribution of lipid 
stained mass using polyacrylamide gradient gels (2- 
14%). LDL particle size analysis is based on a four- 
point curve using lipoprotein standards correlated by 
analytical ultracentrifugation (ANUC). Results of 
phyenotype analysis are validated by comparison of 
GGE analysis with ANUC. 

Plasma high density lipoproteins (HDL) are 
characterized for particle size and distribution of 
protein stained mass using polyacrylamide gradient 
gels (3-31%). HDL particle size analysis is based on 
calibration with globular protein standards. Results 
validated by comparison of GGE analysis with 
analytical ultracentrifugation (ANUC). 
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Patient data from lipid analysis and other data have been utilized to develop a 
knowledge database within the infomediary site. This knowledge base is useful in 
analyzing an individual patient's data and also identifying new and previously unknown 
relationships between test results that aid in the diagnosis and treatment of patients. 
5 Additional relationships are identified from the tables 900 , 902, and 904 using standard 
data mining techniques, including genetic algorithms, decision tree induction, association 
discovery, fuzzy logic, etc. The relationships are then incorporated into the CV 
therapeutic database 906 . More particularly, the relationships may be incorporated into 
programs or scripts (e.g., SQL scripts) within the diagnostic engine 113 . 
10 Considering 954 patient samples (458 cases and 496 controls), age was a very 

significant predictor of CVD. Cases are significantly older than controls (60 vs. 52 years 
of age). After adjusting for the age difference, none of the risk factors are significantly 
^zf different between the cases and controls. Thus, using the 954 patients, all of the 

=J1 differences in risk factors that exist between cases and controls are due to age, not disease 

'£ 15 status. All of these patients are high risk and the younger patients have not yet shown 
T clinical manifestation of cardiovascular disease. 

ijl Using a subset of age matched cases (N=173, means 60 yr.) and controls (N=173, 

i^i means 59 yr.) between 54 and 66 years of age, the cases had significantly: 

Higher homocysteine (9.7 vs. 8.7, P<0.01), and 
!| 20 Lower TC (179 vs. 201, p<0.0001), LDLC (107 vs. 121, p<0.001), triglyceride 

2 (140 vs. 163, p<0.05), apoAl (1 12 vs. 123, p<0.01) apoB (85 vs. 96, p<0.001), and 

TC/HDL2b (14.8 vs. 20.2, p<0.05). These data indicate that the cases are more 
aggressively treated with medications than the controls. 

Using a subset of age-matched cases (N=146, mean 55 yr.) and controls (N=93, 
25 mean 55 yr.) between 44 and 66 years of age without hvperlipidemia. the cases had: 
Higher HDL3b (19.9 vs. 17.9, p<0.05), HDL3 (58.8 vs. 55.7, p=0.08) and 
LDLII+IV/HDL2+3 (0.40 vs. 0.38, p=0.1 1), and 

Lower TC (182 vs. 205, p<0.001), LDLC (109 vs. 124, p<0.01), HDLC (44 vs. 
LDLllA (16.8 vs. 18.2, p=0.09), HDL2b (15.5 vs. 18.6, p<0.05), and HDL2 (41.3 vs. 
30 44.5, p=0.06). These data again indicate that cases may be more aggressively treated 
with medications than the controls, even though they do not have hyperlipidemia. These 
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data also indicate some important risk factors in the cases: a higher ratio of small LDL to 
HDL, small LDL size and lower HDL2b. 

These data illustrate the value of the cardiovascular informatic knowledge base in 
deriving heretofore unrecognized relationships between data, especially highly 
5 discriminating lipoprotein subfractions, in diagnosing risk factors which may govem the 
treatment of patients. 

DETAILED DESCRIPTION OF THE INFQMEDIARY SITE 
In a preferred embodiment, the infomediary (information intermediary) site 100 is 
accessed over a network 101 , either a public network such as the internet, or a private 

10 network such as a private LANAVAN, either of which may be accessed over high speed 
digital subscriber lines or optional dial up (circuit switched) connections provided by a 
remote authentication server or the like. The network 101, as shown in Figure 24, may 
include landline and/or wireless access (typically CDMA), as is known in the 
telecommunications art. 

1 5 The healthcare information is typically displayed on a web browser running on a 

personal computer or other web-content viewing device. In the case of patient access, 
this may include a personal computer 107 with n^r^ access, a television ^^^^pj^ ^ ^^^^ 
top deco^r (such as that provided by WorldGat^^ommunications, Microsoft^iWebTV^^S?'^^'^^ 
OpenT\^meractive television, or the hke), and ^ay also include a cable modem or 

20 wireless modem, or may be a smaller internet appliance device. The patient may also 
utilize tele-medicine devices such as a weight scale 115 , blood pressure cuff 116 , 
electrocardiogram device 117 or other similar monitoring devices. 

In the case of a physician, any of the above access devices may be used. 
Preferably, physicians utilize a portable dejdce such as,a clipboard or tablet computer 107 

25 such as those availa^£|^^^|i^^a Clio^evice avanable from Vadem, or a smaller 

device such as a Pal^^Hfe. The device may have wireless access 111 to the network for 
A 

data transfers, or may store information locally on a computer 103 and periodically 
synchronize with the infomediary site via the network. 

The information pages are conveyed to the browsing device over the network in 
30 the form of a device independent language such as hypertext markup language (html) 
using hypertext transfer protocol (http). These protocols are typically carried by a lower 
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level transfer protocol such as those associated with the TCP/IP protocol suite. The 
device independent language is preferably generated dynamically by the infomediary site, 
using Common Gateway Interface (CGI) scripts, Active Server Pages (ASP), or other 
content generation languages and protocols. CGI and ASP are language-independent 
frameworks for coding of server-side scripts that are executed by Web server 112 in 
response to a user's request for a universal resource locator (URL). The infomediary site 
may also be accessible from an interactive television channel having regular multimedia 
displays of health-related educational information, documentaries, and the like, with the 
healthcare management features described herein being accessible to patients using 
10 software or scripts written in accordance with known integctive television transmission 
platforms and protocols, such as that provided by OpenT^^ suite of EN2 set-top box 
software, software development tools, studio authoring tools, and Openstreamer data 
streaming software. 

In response to user requests, the infomediary server scripts 112 access the 
15 database 104 , which contains numerous data tables as shomi in Figures 18-22. For 
example, ASP scripts provide database access via Microsoft^ ActiveX Data Objects 
(ADO), ^^^h albws access to ^fl^ OLEDB compljgjit data source including 
^ftT^cces&^Jet), Microsoft^QL 



^ ^ MicrosofrAcces&^Jet), Microsoft^QL Server, and Oracle-oatabases. 

The data tables will now be described with reference to Figures 18-22. The 
20 various tables in Figures 18-22 make up a relational database, where the tables are related 
as indicated by the interconnecting lines. As is known to those of skill in the art, tables 
within relational databases may exhibit a one-to-many relationship. An exemplary 
description of such a relationship will be given with reference to the UserlD of the 
TWebUsers table 800. The remaining tables are related in a similar manner as is 
25 apparent from the drawings. 

Table 800 contains a record for each of the users of the infomediary site 100 . 
Each UserlD is a unique number defining a particular user's characteristics, including 
their login name, password, usertype, and a timestamp indicating when the record was 
created. The tables 801 , 803, and 805, all include fields that are linked to the UserlD 
30 within table 800. The key symbol at the end of the lines connected to table 800 indicate 
that the value within the UserlD field specifies a unique record within the tWebUsers 
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table 800, while the infinity symbol on the other end of the lines connected to tables 801 , 
803 , and 805 indicate that more than one record in those tables can be linked to the same 
UserlD in table 800. As is know to those of skill in the art, relating the tables in this 
manner results in a more efficient and powerful database structure than a single large data 
5 table. 

The table contents will now be generally described, in view of the above-defined 
relationships. When a patient initially registers with the infomediary site 100, he or she is 
associated with a physician. The registration is typically performed by the physician's 
office assistants (independently or with the aid of infomediary site personnel) in advance 

10 of the patient's first visit to the infomediary site. With reference to Figure 20, client 
patient table 84Q links a patient's webuser ID to the relevant physician webuser IDs. 
Table 841 links physicians (by the clientID) to a physician profile including an affiliated 
hospital, degree, and region (further described in client region table 844). As shown in 
client assistant map table 842 , each physician assistant has an assistant ID, a clientID 

15 (i.e., physician), and a permision level (as described in permission level table 843) . 

Physicians may be categorized according to client category map table 846 (as described 
by client news category table 847 , and news stories may be categorized as shown in table 
845 . 

With reference to Figure 18, tables 801, 802, 803, 804, 807 and 808 are used to 
20 gather the patient history data. Either the patient or data entry personnel (such as a 

physician's assistant or a case manager or technician provided by the infomediary site) 
using an appropriate interface (preferably a GUI, such as a web browser, or another 
database entry interface) collects data that is inserted into the tables. The tables are 
preferably accessed using a data entry interface such as the web pages provided by the 
25 web server 112 . When the patient or data entry personnel navigate to the relevant input 
screens, the database management system 115 (or server scripts 112, such as ASP server 
scripts) queries the question map table 801 to determine which questions the physician 
wishes to ask his patients. Each physician (identified by the ClientID field in table 801 , 
which is in turn linked to a UserlD in table 800) may create a customized list of questions 
30 fi'om a question pool. The list of questions is stored as individual records in table 801 
corresponding to that physician. The questionlDs are used to retrieve the question text 
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and response format from question pool table 808. The description of the response 
format is then obtained from table 809 , and the question is presented to the patient. If the 
patient is accessing the site directly, the questions are preferably presented in the form of 
web pages to the patient. If data entry personnel are utilized, the question may be read to 
5 the patient to solicit the response. The responses are entered and submitted to the 

database system, and are stored in tables 802 and 803. Tables 804, 805, 806, 809, 810 
and 811 are used in a similar to gather compliance information. 

With reference to Figure 19, tables 820, 821 and 822 are used to gather guest 
information, including requests for information and contact information. Tables 825 and 

10 826 are used to provide a commxmication interface that facilitates communication 

between physicians and patients. The sender and receiver are identified, along with the 
subject, body, date, time and priority, etc. Thus, when a physician logs in and requests to 
view his email, the communication interface, preferably made up of server scripts and 
database management software, queries email table 826 for all entries having the 

15 physician's UserlD (table 800) in either the senderlD or receiverlD field. Those entries 
may be looked up in email audit table 825 to check the status. 

Table 827 keeps a log of frequently asked questions (FAQs - as stored in FAQ 
table 824) that have been accessed by a given patient, thus allowing a physician to obtain 
further information about potential concerns of his or her patients. With reference to 

20 Figure 21, Letters of consultation may be created using tables 850, 851 and 854 . New 

diagnoses are created via the physician data access interface and stored in table 852. The 
template for creating a diagnosis may be created using standard diagnostic phrases 
obtained from tables 853 and 856. The new diagnosis template may present the 
cardiologist with certain diagnosis suggestions based on the test results. Specifically, the 

25 diagnostic 113 engine may perform algorithmic tests on new test results and store one or 
more diagnosis candidates in diagnosis fields (not shown) in the test results table 902. 

With reference to Figure 22 treatment plans are stored in tables 860 - 865 . 
Physicians, through the physician data access interface, create treatment plans for 
individual patients. Typically, the treatment plan is created or updated after test results 

30 become available. The treatment plan template is preferably generated and stored in 
treatment plan table 860, reading assignment table 861 , Exercise assignment table 862 , 
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diet assignment table 863, CV product assignment table 864 , and education assignment 
table 865 . Tables 866, 862, 868, 869, 870, 871 and 872 are used to store possible 
selections for the corresponding tables as shown in Figure 22. When a treatment plan 
template is generated for the physician, the diagnostic engine may be utilized to query 
5 Diagnosis table 852 and responsively determine suggested treatment plan components to 
be displayed as a suggested treatment plan within the template. 

The diagnostic engine may also query relevant test result tables, patient history 
tables, comphance tables and the like to determine the suggested treatment plan. Prior to 
the cardiologist's review of the suggested treatment plan, the case manager or physician's 

10 assistant may initially access it to review it. The case manager may modify the plan or 
accept it and submit it to the cardiologist for final approval and posting to the patient's 
folder where the patient may view the plan. 

With respect to Figure 25, the flow chart for the method 1000 will be described. 
At step 1002 the test result data is stored. As described herein, the test data may be 

1 5 received over a network fi"om a lab. At step 1004 the test result data is supplied to the 
physician. Preferably, the test data is provided using web pages conveyed over a 
network. At step 1006 the site receives diagnostic data firom the physician. The 
diagnostic data is stored in the database as part of the patient's record. At step 1010 the 
site receives treatment plan information from the physician. The treatment plan is 

20 likewise stored in the patient's record. At step 1012 the site provides treatment plan 
information to the patient, also via web pages conveyed over a network. 

With respect to Figure 26, the flow chart for the method 1100 will be described. 
Steps having the same number as in the method 1000 are essentially the same. However, 
the method 1100 includes additional steps. At step 1003 the test result data is analyzed. 

25 The analysis is preferably performed using diagnostic engine 113 . The diagnostic 

analysis information is stored in a table and associated with the relevant test results. The 
diagnostic analysis data is preferably one or more suggested diagnoses based upon the 
test results and other salient data from the clinical database 105 and information database 
104 . At step 1005 the test result data and the diagnostic data is supplied to the physician. 

30 At step 1007 the site analyzes the diagnostic data received fi^om the physician. The 
analysis preferably identifies possible treatment plan information, including possible 
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prescriptions, diets, exercises, CV products, educational materials, etc., as discussed 
above. It should be noted that information identified as being provided to and received 
from the physician may actually be submitted and received by a physician's assistant, 
nurse, or other responsible party. The term physician is used in this context to refer to the 
fact that the submission of diagnosis and treatment plans should be performed imder the 
supervision of a physician. 

A preferred embodiment of the present invention has been described herein. It is 
to be understood, of course, that changes and modifications may be made in the 
embodiment without departing fi"om the true scope of the present invention, as defined by 
the appended claims. The present embodiment preferably includes logic to implement 
the described methods in software modules as a set of computer executable software 
instructions. The Computer Processing Unit ("CPU") or microprocessor implements the 
logic that controls the operation of the site, diagnostic engine, and database. The 
microprocessor executes software that can be programmed by those of skill in the art to 
provide the described fimctionality. 

The software can be represented as a sequence of binary bits maintained on a 
computer readable medium including magnetic disks, optical disks, and any other volatile 
or (e.g., Random Access memory ("RAM")) non-volatile firmware (e.g., Read Only 
Memory ("ROM")) storage system readable by the CPU. The memory locations where 
data bits are maintained also include physical locations that have particular electrical, 
magnetic, optical, or organic properties corresponding to the stored data bits. The 
software instructions are executed as data bits by the CPU with a memory system causing 
a transformation of the electrical signal representation, and the maintenance of data bits at 
memory locations in the memory system to thereby reconfigure or otherwise alter the 
unit's operation. The executable software code may implement, for example, the methods 
as described above. 

It should be understood that the programs, processes, methods and apparatus 
described herein are not related or limited to any particular type of computer or network 
apparatus (hardware or software), unless indicated otherwise. Various types of general 
purpose or specialized computer apparatus may be used with or perform operations in 
accordance with the teachings described herein. 
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In view of the wide variety of embodiments to which the principles of the present 
invention can be appUed, it should be understood that the illustrated embodiments are 
exemplary only, and should not be taken as limiting the scope of the present invention. For 
example, the steps of the flow diagrams may be taken in sequences other than those 
described, and more or fewer elements may be used in the block diagrams. 

It should be imderstood that a hardware embodiment may take a variety of 
different forms. The hardware may be implemented as one or more server computers. 
For example, the web server may reside on one computing platform that accesses the 
database system residing on another computing platform. 

The claims should not be read as limited to the described order of elements unless 
stated to that effect. In addition, use of the term "means" in any claim is intended to 
invoke 35 U.S.C. §112, paragraph 6, and any claim without the word "means" is not so 
intended. Therefore, all embodiments that come within the scope and spirit of the 
following claims and equivalents thereto are claimed as the invention. 
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